A file system journal is used to provide more efficient (and sometimes, more accurate) repair of a file system in the event of a crash, power outage, or other failure to properly un-mount the file system, compared to a file system without a journal or similar mechanism. A journal is used to speed recovery when mounting a volume that was not un-mounted safely. Journaling makes it quick and easy to restore the file system data structures to a consistent state without having to scan all the structures.
In a journaling file system, a journal entry is written before each file system change, describing the change to be carried out. This allows quick recovery if the actual file change is interrupted or not carried out due to power outage or whatever. Journaling does not protect your (new) data, it just prevents inconsistencies. Data changes are written to the journal before committing the data changes to physical disk. Once the data has been safely confirmed as being on disk, the record is erased in the journal. If a failure occurs while writing to the journal, the original data is still in a consistent state except that the new, pre-crashed data that was being written is lost. What a journaling file system really protects against are situations where the power is cut off in the middle of a write, and the file system gets left in an unstable state. By using a journaling process, if the power does click off, any half-completed operations can be replayed and brought back into a stable state. Basically, journaling ensures that when a group of related changes are being made, either all of those changes are actually made, or none of them are made. This is done by gathering up all of the changes, and storing them in a separate place (in the journal). Once the journal copy of the changes is completely written to disk, the changes can actually be written to their normal locations on disk. If a failure happens at that time, the changes can simply be copied from the journal to their normal locations. If a failure happens when the changes are being written to the journal, but before they are marked complete, then those changes are ignored.
When a file system is updated (for example, to create or delete a file), several data structures within the file system typically need to be changed. The journal is used to ensure that all or none of these changes are actually applied. The changes are all written to the journal, and the journal header is updated to indicate that all the changes have been made. After the changes to the journal and journal header have been written to disk, then those changes may be written to the normal data structures. In the event of a crash after the journal header has been written, but before the changes have been written to the normal data structures, the changes can be “replayed” by reading them from the journal, and writing to the normal data structures. This ensures that all the changes have been made. In the event of a crash before the journal header has been written, then the incomplete changes in the journal are ignored, and none of the changes will have been made to the normal data structures. Thus, every update is “all or nothing.” Once all changes have been written to the normal data structures, the changes can be removed from the journal by updating the journal header. Without a journal or a similar mechanism, you would have to verify and potentially repair every data structure in the file system, which can take a very long time.
Some data processing systems available today are operable to include more than one file system currently running on a host processor. These systems allow for more than one operating system to function on the same hardware. For example, a system may contain both a Mac OS-based operating system and a Microsoft Windows-based operating system. However, in order to maintain compatibility, two separate files systems are needed, each potentially requiring its own contiguous space within the system's physical memory space. When a second file system is placed within the memory of such a system, the physical memory space should be partitioned into two contiguous regions and the first file system must be resized in order to make room on the disk to install the second operating system.
One problem that arises is that the resized file system now corresponds to a smaller area (or volume) on a memory space and may have data structures located in the new volume corresponding to the second file system placed on a memory space within such a system. The resized file system may be currently storing data or other structures in the location where the new file system will be put, and the content of the resized file system must be relocated to make room for the new file system. Many operating systems in use today do not have a mechanism to relocate the file system data structures, which results in failure of the associated volume upon resizing and a user will be prevented from installing the dual file system in the partitioned memory space.
Another problem is that the normal file system data structures must be updated in order to change the location of the journal. For example, the blocks occupied by the old journal must be freed, the blocks occupied by the new journal must be allocated, and the location of the journal in its catalog file record must be updated. None of the updates may be written until after the new journal has been set up and made active. If there was a crash or power outage after the new journal was made active, but before the corresponding changes to the normal data structures were written, the file system would be damaged, defeating the purpose of a journal. If those changes were written to the old journal as they normally would, they would not be automatically replayed because they were not active (new) in an active journal. The normal method of making changes to the file system data structures involves starting a transaction, adding modified blocks to the transaction, then ending the transaction. When the transaction is ended, the modified blocks are written to the journal, the journal header is updated to indicate that the transaction is complete and valid, and then the modified blocks are written to the normal data structures within the physical memory space. But this won't work for relocating the journal itself, since the modified blocks might get written to the journal data structures before the journal info block has been updated to point to the new journal, as mentioned above.